1. Field of the Invention
The present invention relates to distributed systems configured to process requests provided in different formats.
2. Background of the Related Art
Wide area networks such as the Internet provide a convenient forum for engaging in a variety of commercial activities, generally referred to as eCommerce. A typical eCommerce environment 100 comprising buyers and sellers connected by the Internet is illustrated in FIG. 1. In the illustrative buyer/supplier model, a buyer organization 102 has purchased procurement software 103 from a third party vendor. The procurement software 103 allows an individual in the buying organization 102, commonly referred to a requisitioner 104, to use a browser to make purchases. The requisitoner 104 can choose from a list of approved catalogs and shop for the desired items. The catalogs are hosted locally at the buyer organization 102 on a catalog server 106. The catalog information is uploaded to the catalog server 106 by a supplier 1101, 1102, . . . 110N. Each supplier 110N is responsible providing their catalog information to the buyer organization 102.
Viewing the catalog, the requisitioner 104 selects the items and quantities needed. When finished, this order is submitted and captured by the procurement software.
The procurement software 103 next notifies a designated approver 108 that a new order request has been placed. The approver 108 is part of the buying organization and uses a browser to view the order and make any necessary changes in price and/or quantities. If the request looks satisfactory, the approver 108 approves the order request.
An approved order request results in a purchase order (PO) message being sent by the procurement software 103 to the appropriate supplier 110N of the goods. The supplier 110N accepts the PO, processes it as necessary and sends a PO response message to indicate that the order was accepted.
FIG. 2 shows an alternative eCommerce environment 200 in which a requisitioner 204 of a buying organization 202 is provided with the ability to shop from a remote catalog hosted directly at the web site of a supplier 210N. In this scenario, the requisitioner 204 again uses a browser to choose an approved catalog to shop from. The procurement software 203 then indicates that the catalog is hosted remotely. The procurement software 203 obtains, either from local storage or from the supplier site, the URL to use for shopping the catalog and returns this information to the browser of the requisitioner 204. The requisitoner 204 then shops the remote catalog and places items in a shopping cart. Upon completion, the requisitioner 204 confirms the order and checks out. The supplier 210N is then responsible for sending the shopping cart contents to an approver 208 of the buyer organization 202. The remaining steps are as those described with reference to FIG. 1. Thus, the approver 208 approves the order and causes a PO to be sent to the supplier 210N. The supplier 210N processes the PO by integrating it with back-end applications or by directing it to a commerce application for processing.
One problem with conventional eCommerce systems is that the buying organizations are installing newer versions of procurement software in an attempt to streamline the purchasing process and reduce expenses. These versions utilize protocols not supported by the legacy systems of the suppliers. These protocols include XML-based protocols, such as Commerce XML (cXML), which allow buyers to communicate with multiple seller organizations. Accordingly, buyers are motivated to do business with suppliers that support the new protocols. Suppliers must therefore support these new protocols or be at a competitive disadvantage to those sellers who do support the protocols. To this end, suppliers must either install new applications or find a means to support the new protocols using the existing order processing software (e.g., reprogram the legacy equipment). Installing new applications and reprogramming existing software are both cost prohibitive and therefore not viable solutions.
There are several existing products that attempt to address integration of existing business solutions with defined B2B protocols. In general, exiting solutions allow an XML formatted message to be mapped to one or more business applications for processing. However, the user is required to have knowledge of all fields in the XML message that apply to a given type of B2B request. Furthermore, some products require a unique adapter program to be generated for each B2B request type to be mapped to a given business application. This adapter program must be ported, compiled and installed on the platform hosting the target business applications.
Therefore, there is a need, in an eCommerce environment, to process requests having various formats including formats not originally/directly supported by supplier""s applications.
Systems, methods, and articles of manufacture are provided for processing eCommerce transactions. In one embodiment, a system for handling eCommerce requests is provided. The system comprises at least one application configured to process a request in a transformed format, wherein the request is received from one of a plurality of requesting entities in an original format and mapped to the transformed format. At least one specification document is configured to produce metadata defining a relationship between data of the request in the original format and data of the request in the transformed format. A flow manager is configured to utilize the metadata to map the request in the original format to the request in the transformed format and to call the at least one application.
In still another embodiment, a system for handling eCommerce requests received from one of a plurality of requesting entities is provided. The system comprises at least two applications each configured to process requests in a transformed format; wherein a first application is configured to process a first request type and a second application is configured to process a request of a second type. At least two access methods are each configured to define an interface for the at least two applications. Illustratively, the at least two access methods comprise a first access method configured for the first request type and for the first application and a second access method configured for the second request type and for the second application. A flow manager is configured to utilize metadata to map the requests from an original format to the transformed format and to call one or more of the at least two applications.
In yet another embodiment, a method of processing eCommerce requests is provided. The method comprises receiving a request of a first request type comprising a first plurality of input fields; determining an application to invoke, wherein the application is configured to process a request of a second request type comprising a second plurality of input fields; invoking an access method, wherein the access method is configured to define an interface of the application for the second request type; mapping at least a portion of the first plurality of input fields to the second plurality of input fields; and invoking the application.
In still another embodiment, a signal bearing medium, comprising a program which, when executed by a processor, performs a method processing eCommerce requests is provided. The method comprises receiving a request of a first request type comprising a first plurality of input fields; determining an application to invoke, wherein the application is configured to process a request of a second request type comprising a second plurality of input fields; invoking an access method, wherein the access method is configured to define an interface of the application for the second request type; mapping at least a portion of the first plurality of input fields to the second plurality of input fields; and invoking the application.
In still another embodiment, a data structure is configured as an interface definition of a message format of a particular eCommerce transaction type. The data structure comprises protocol information identifying a protocol and the particular eCommerce transaction type, request data format information identifying a request message format for the particular eCommerce transaction type, wherein the request message format comprises a plurality of input fields and input field information identifying at least a portion of the plurality of input fields.
In still another embodiment, a data structure is configured as an interface definition of a request message format and a response message format of a particular eCommerce transaction type. The data structure comprises protocol information identifying a protocol and a transaction type; request data format information identifying the request message format, wherein the request message format comprises a plurality of input fields; and input field information identifying at least a portion of the plurality of input fields. The plurality of input fields includes input fields for at least two different request types and the input field information represents only a first request type. The data structure further comprises response data format information identifying a response message format, wherein the response message format comprises a plurality of output fields; and output field information identifying at least a portion of the plurality of output fields. The plurality of output fields includes output fields for the at least two different request types and the output field information represents only the first request type.